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1 What is the technical problem that was to be solved? 

Mobile IP defines a protocol that allows transparent routing of IP datagrams sent by a Correspondent 
Node (CN) (any Internet node that wants to communicate with a Mobile Node) to a Mobile Node (MN) in 
the Internet. IP paging protocol will be an extension to Mobile IP to allow dormant mode operation, i.e. 
save battery when not receiving/sending IP datagrams. Mobile node alternates between dormant and 
active modes to conserve its power. Mobile node does not perform location updates as long as it is in 
dormant mode. IP paging is a Layer-3 protocol used to find the paging area, in which the MN is located 
and to alert MN to come out of dormant mode, whenever there is an incoming traffic. Paging problem 
statement [3] defines the terminology and the problem of why IP paging is needed. Paging requirements 
document [1] defines architecture and a set of requirements that any IP paging protocol should conform. 

IP paging protocol will benefit from a link layer (layer-2 or L2) operation if the link layer (Layer-2 or L2) 
could provide timely information to network layer (Layer-3 or L3) about the progress of events in layer-2. 
Layer-2 can pass information to layer-3 using triggers. Triggers and their associated application 
programming interface (API) defined in this patent can be used in the implementations of lETF's IP 
paging protocol, for gracefully bringing down layer-3 interface of the MN. In this document, triggers are 
defined as callback functions in C-language. 

2. What were the best existing solutions (known to the inventor)? 

To the authors 1 best knowledge, no existing documents/proposals defined paging triggers or its 
associated API. Triggers related to handoff were discussed in some earlier Internet drafts. 

3. Why were these existing solutions not good enough? 

There are no existing proposals, which define triggers and the associated C-Ianguage API for IP paging. 
Considering the L2 triggers for handoff that appeared in some recentblnternet drafts, the motivations 
behind defining paging triggers and handoff triggers are different. Layer-3 handoff and context transfer 
protocols use handoff triggers to reduce latency in configuring a new interface for the mobile node at the 
new access point. Paging triggers can be used to gracefully bring down layer-3 configuration of MN and 
to detect the movement of MN in dormant mode to another subnet. 
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4. What is the basic idea of the new solution described here? (Please make 
clear how this is different from the existing solutions) 

The events in layer-2 are notified to upper layers through triggers. This document identifies triggers 
related to IP paging and defines them in the form of an application programming interface. Any new IP 
paging protocol to be standardized by IETF and the potential implementations of IP paging protocol will 
benefit from the API defined in this document. Basic uses of defining paging API can be listed as follows. 
The entities Mobile Node and Access Router are as indicated in the figure given below in Section 4.1. 

Mobile Node can possibly use these triggers to 

• Prepare for configuring layer-3 interface when mobile node comes out of dormant mode. 

• Gracefully bring down L3 configuration of MN when it switches to dormant mode 

• Detect that current L3 configuration at MN may possibly be invalid, i.e Detect the movement of MN to 
a different subnet in idle mode. 

Access Routers can possibly use these triggers to 

• Detect the change in status of connection of MN(dormant/active/lnactive) 

• Determine if the MN is reachable {i.e. not in Inactive mode} 

• Communicate among themselves to quickly reconfigure MN, when it comes out of dormant mode 

This document doesn't discuss the ways of implementation of paging triggers. Typically, they may be 
implemented by callback functions (or) interrupts (or) an application layer protocol. Whenever the mobile 
node decides to enter sleep mode (dormant mode) (or) whenever the MN is a paged, layer-2 can pass the 
information to layer-3 using the triggers, defined in this document. Layer-3 can use this information to 
prepare for disconnection from existing layer-3 interface (or) to prepare for configuring a new layer-3 
interface as soon as MN comes out of dormant mode. 
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4.1. Pictorial representation of the solution: 



AP-> Access Point 
AR-> Access Router 
HH-> Hobile node 



Triggers at 

Access 

Router 





5. Description of the solution 

Glossary of terms used in defining triggers: 

• Paging area: Network may be divided into a set of areas called L2 paging areas. As long as MN 
moves within a single paging area, it need not perform location updates. The paging area refers to a 
layer-2 paging area as defined in the cellular systems of GPRS (or) UMTS standards. 

• Paging agent : A node which distributes paging requests to MN upon the receipt of an incoming call 

• New paging area: The layer-2 paging area into which MN has just moved 

• Paging request : Layer-2 message used to notify MN that there is an incoming call 

• Access Router (AR): The node with which MN has registered its layer-3 binding. Here AR is a generic 
term used to refer to "Access Router" in Mobile IPv6 and "Foreign Agent " in Mobile IPv4. 
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Triggers that are identified to be useful for IP paging are: 



L2 trigger 


When 


i 

| To 


Parameters 


MN paged 


As soon as MN gets layer-2 
paging request 


MN 


Paged L2 address, 
Paging agent request 
L2 Address 


New Paging area 




As soon as layer-2 paging 
area changes 


| MM 


New Paging area L2 
address 


New Paging mode 


As soon as MN changes its 
mode (active/ dormant 
/inactive) 


MN 


New mode 


Dormant MN 
reachable 


As soon as network detects 
that a dormant MN is 
reachable {Previously 
network had information that 
dormant MN is unreachable} 


Uj/^s -ft* 
AR 


-none- 


Dormant MN not 
reachable 


As soon as network loses 
track of a dormant MN.i.e. 
MN, which got disconnected 
from the network without 
making necessary updates 


' AR 


-none- 


Start of L2 Paging 
request 


As soon as L2 paging of MN 
starts 


All Access 
Routers / fn\_ 
I whose area, 
| paging is done 


MN's L2 address 



These triggers can be defined in the form of an API. The remaining part of this section defines 
the C-language API. — 



5.1. Basic structures used in API: 

Triggers are defined as callback functions. Applications register with these callback functions 
which in turn notify as soon as layer-2 trigger is fired. The trigger functions are blocking, in the 
sense the applications are blocked at the point they call these trigger API, until the trigger is 
fired. 
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API assumes that characters are 8-bit wide and integers are 16-bit wide. All the strings (or) 
array of characters used in API are standard null terminated 'C strings. Callbacks are used to 
define API. A library of callbacks can be defined, each representing one function of Layer-2 
API. Concurrency in processing these triggers can easily be provided by using threads or 
processes. The data types of structure elements given in this patent are intended to be 
examples, not strict requirements. 

5.1 .1 . Format of data types 

Primitive data types, used in this document, follow the POSIX format. POSIX format is a 
standard format for defining APIs [2]. e.g. uintN_t means an unsigned integer of exactly 'N' bits. 

5.1.2 I Pv6/IPv4 Address [2] 

This data structure contains an array of sixteen 8-bit elements, which make up one 128-bit Ipv6 
address. IPv6 address is stored in network byte order. 

For IPv6, layer-3 address is defined as 
struct in6_addr{ 
uint8_ts6_addr[16]; 

}; 

For IPv4, layer-3 address is defined as 
struct in4_addr{ 
unit8_ts4_addr[4]; 

}; 

Typecast "network_addr" to the addressing structure, used in the system as follows: 
#ifdef PFJNET6 

typedef struct in6_addr struct network_addr; 
#endif 

#ifdef PFJNET4 

typedef struct in4_addr struct network_addr; 
#endif 

5.1 .3 Layer-2 address and paging area ID 

This structure assumes that the size of layer-2 address is 64 bits [4]. If a specific L2 has a 
different size it should be defined accordingly. 

struct I2_addr{ 
uint8_t link_addr[8]; 
} 

typedef uint8_t layer2_paging_area_ID; 

API assumes that paging area ID is of size 64 bits. If the size of paging area ID is different, it 
should be changed accordingly. 



5.1.4. Return codes 
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A list of error codes, which may be returned by callbacks, can be defined as follows 

typedef enum 
{ 

L2_TRIGGER_RETURN =0 
L2_TRIGGER_ERR_NOT_DEFINED, 
L2_TRIGGER_ERR_SECURITY, 
L2_TRIGGER_ERR_NOT_SUPPORTED, 
L2_TRIGGER_ERR_CANNOT_REGISTER_HERE ( 
L2_TRIGGER_ERR_TIMED_OUT, 
L2_TRIGGER_ERR_ALREADY_REGISTERED, 
L2_TRIGGER_ERR_NOT_REACHABLE 
} L2APIReturnCode; 

The following is a description of the reasons when the error codes are returned 

Explanation of return codes 

5.1 .4.1 L2_TRIGGER_RETURN: This code is returned if the trigger is successfully caught. 

5.1 .4.2 L2_TRIGGER_ERR_NOT_DEFINED: This code is returned when a function tries to 
register an undefined callback. 

5.1.4.3. L2_TRIGGER_ERR_SECURITY: This error is returned, if L2 prevents L3 from catching 
the trigger for security reasons 

5.1 .4.4. L2_ERR_NOT_SUPPORTED: This error code is returned when L3 tries to register a 
well-defined trigger, which is not supported by the underlying L2. 

5.1 .4.5. L2_TRIGGER_ERR_CANNOT_REGISTER_HERE: This error code is returned if the 
callback of trigger is not allowed at the place, this function was called. 

5.1 .4.6. L2_TRIGGER_TIMED_OUT: This error code is returned, if the trigger did not occur for 
certain amount of time after the callback was registered. L2 does not remember this callback 
any more. 

5.1 .4.7. L2_TRIGGER_ALREADY_REGISTERED: This error code is returned if an application 
has already registered this callback and if the same callback cannot be registered by two or 
more applications. 

5.1 .4.8. L2_TRIGGER_ERR_NOT_REACHABLE: This error code is returned if an application 
tries to catch a trigger for MN, which has a state " unreachable" in layer-2. This can be because 
MN has not performed location/periodic updates. 



5.2. Paging API: 

5.2.1. MN paged 

This trigger must be sent to MN as soon as it gets a paging request. The access point from 
which it received the address and the ID of the paging area are the parameters of the trigger. 

void catch_trigger_MN_paged(L2_address*, paging_area_ID*, L2APIReturnCode* code); 



attorney-clientWivileged confidential information 

Local Docket No. 

Alcatel Reference No. 8BD 0304 0341 URZZA 

5.2.2. New paging area 

This trigger must be sent to layer-3 at MN as soon as MN finds that it has changed layer-2 
paging area. New paging area ID is sent as parameter. 

Paging_Area_ID new_paging_area(L2APIReturnCode* code); 

5.2.3. New paging mode 

Layer-3 at MN must be informed by layer-2 whenever it changes its mode. 
(Dormant/Active/Inactive) 

int new_paging_mode_trigger(L2APIReturnCode* code); 
The return values of the function are 

0 for dormant mode 

1 for Active mode 

2 for inactive mode 

5.2.4. Start of paging request 

This trigger should be sent to layer-3 in all subnets within the paging area. All the access 
routers need not be informed at the same time. 

L2_address paging_request_start(L2APIReturnCode* code); 

5.2.5. Dormant MN reachable 

As soon as MN reconnects to the network, this trigger should be sent to layer-3 at the Access 
Router, where MN has registered its layer-3 interface. This trigger should be sent to layer-3 
only when MN's state in layer-2 changes from "unreachable" to "reachable". 

void dormant_MN_reachable(L2APIRetumCode* code); 

5.2.6. Dormant MN not reachable 

This trigger should be sent at layer-3 of access router, as soon as network detects that MN is 
not reachable. This trigger should be sent to layer-3 only when MN's state in layer-2 changes 
from "reachable" to "unreachable". 

void dormant_MN_not_reachable(L2APIReturnCode* code); 
6 References: 

[1] RFC 3154 , Requirements and Functional Architecture for an IP Host Alerting Protocol 

[2] RFC 2553, Basic Socket Interface Extensions for IPv6 

t 3 l RFC 3132, Dormant Mode Host Alerting ("IP Paging") Problem Statement 
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Abstract 



A critical factor in achieving good performance for IP mobility 
protocols is the design of L2 handover. Handover occurs when a 
Mobile Node moves from one radio Access Point to another. If the new 
radio Access Point is associated with a new subnet, a change in 
routing reachability may occur and require L3 protocol action on the 
part of the Mobile Node or Access Routers. If no change in subnet 
occurs, the Access Point may still need to take some action to 
inform the Access Router about a change in on-link reachability. In 
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either case, prompt and timely information from L2 to the parties 
involved about the sequencing of handover can help optimize handover 
at the IP level. This draft discusses requirements for an L2 
handover protocol or API to support optimized handover. 
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0 Introduction 

An important consideration in the design of IP mobility protocols is 
handover. A moving Mobile Node (MN) may irregularly need to change 
the terrestrial radio Access Point (AP) with which it is 
communicating. The change in L2 connectivity to a new AP may cause a 
change in IP routing reachability, and thus require either the MN or 
the Access Routers (ARs) to perform actions that update routing 
information for the MN. Even if no change in subnet occurs, the APs 
may still need to communicate the change in on-link reachability to 
the local AR. In order for handover to occur, candidate APs must be 
identified and a target AP must be selected [10] . Once this process 
has been complete, the handover process can begin. 

Several protocol designs have been advanced for Mobile IP that seek 
to reduce the amount of handover latency at L3 [3] [4] [5] . These 
protocols depend on obtaining timely information from the L2 
protocol about the progress of handover. An additional beneficiary 
of timely handover progress information is context transfer [6] . 
Context transfer involves moving context information (QoS, header 
compression, authentication, etc.) from the old AR to the new. By 
moving such context information, the ARs can avoid requiring the MN 
to set up all the context information from scratch, considerably 
reducing the amount of time necessary to set up basic network 
service on the new subnet. If handover progress information is 
available from L2, context transfer can proceed more quickly. 
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This document discusses requirements for an L2 handover protocol or 
API to support optimized L3 handover. While the document has been 
written with existing Mobile IP work in mind, it should be 
applicable to any protocol that can benefit from knowledge about L2 
events to facilitate mobility. Requirements for assisting in 
handover between two APs on the same subnet, between two ARs on 
different subnets, and for context transfer between ARs are 
discussed. 

0 Terminology 

The following terms are used in this document. 

Access Point (AP) 

A Layer 2 (L2) access entity, e.g. a radio transceiver 
station, that is connected to one or more Access Routers. Its 




primary function is to provide MNs an L2 wireless link via its 
specific air-interface technology. 

Access Router (AR) 

A Layer 3 (L3) IP router, residing in an access network and 
connected to one or more Access Points. An AR is the first hop 
router for a MN. 

L2 Handover 

Change of MN's link layer connection from one AP to another. 
No change in off-subnet routing reachability information is 
required . 

L3 Handover 

Change of MN's routable address from one AR to another. An L3 
handover results in a change in the MN's routing reachability , 
that will require action on the part of the IP mobility 
protocol running in the MN and/or ARs . 

3.0 L2 Trigger Definition 

This section discusses defining L2 triggers that provide information 
on the sequencing of handover. An L2 trigger is not associated with 
any specific L2 but rather is abstracted from the kind of L2 
information that is or could be available from a wide variety of 
radio link protocols. 

3.1. What is an L2 Trigger? 

An L2 trigger is an abstraction of a notification from L2 
(potentially including parameter information) that a certain event 
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has happened or is about to happen. The trigger may be implemented 
in a variety of ways. Some examples are: 

- The L2 driver may allow the IP stack to register a callback 
that is called when the trigger fires. The parameters 
associated with the trigger are delivered to the callback. 

- The operating system may allow an application layer thread to 
call into a system call for the appropriate trigger or 
triggers. The system call returns when a particular trigger has 
fired, with parameter information as a return value of the 
system call. 

- The trigger may consist of a protocol for transferring the 
trigger notification and parameter information at either L2 or 
L3 between the new AP or AR and the old AP or AR. The parameter 
information is included as part of the protocol. This allows 
the IP stack on a separate machine to react to the trigger. The 
IAPP protocol [7] is an example of such a protocol. 

In any case, the implementation details of how the information 
involved in an L2 trigger are transferred to the IP mobility 
protocol are likely to color how the mobility protocol is 
implemented on top of that L2, but they should not influence the 
specification of the abstract L2 triggers themselves. 

3.2. Information in an L2 Trigger 
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There are three types of information involved in defining an L2 
trigger: 

1. The event that causes the L2 trigger to fire, 

2. The IP entity that receives the trigger, 

3. The parameters delivered with the trigger. 

The IP entities that can receive the trigger depend on the 
particular IP mobility protocol in use. Here are some possible IP 
entities, based on work done with L2 triggers and Mobile IP: 

MM The MN may receive an L2 trigger allowing it to start 

or conclude a mobile controlled handover. 

FA In Mobile IPv4, the Foreign Agent (FA) is located on 

the last hop before the wireless link. The last hop 
can be either an AP or AR or even a separate host. 
An FA can make use of triggers to start or conclude 
network controlled handover. 

AH The AR can obtain an L2 trigger directly from the 

wireless link if one of its interfaces is on the 
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link (that is, the AR is also an AP) , or it can obtain 
an L2 trigger indirectly by L2 or L3 protocol messages 
from the AP. 

4.0 L2 Handover Requirements for L2 Triggers 

On the face of it, specifying requirements for pure L2 handover 
(i.e. no change in IP routing reachability) might seem out of scope 
for IETF . Existing wireless networks typically have special L2 AP-AR 
interfaces with L2 address update built in. For these systems, L2 
triggers are unnecessary. 

However, current trends in wireless networking suggest that future 
wireless networks will consist of a variety of heterogeneous 
wireless APs bridged into the wired network, potentially on the same 
subnet. A change in wireless AP, either between an AP supporting one 
wireless link technology and an AP supporting another, or between 
two APs supporting the same wireless technology, necessarily results 
in a change in the on-subnet reachability. Packet delivery within 
the subnet can be optimized if this information can be propagated to 
the AR, so it can update its on-subnet L2 address to IP address 
mapping. 

In addition, the old AP may benefit from a notification that the MN 
has moved in the event it is not involved in the handover (as is the 
case with some WLAN radio protocols) , by allowing the old AP to more 
quickly de-allocate resources dedicated to the moved MN. Some radio 
link protocols already define IP-based L2 trigger protocols for this 
purpose [7] . When APs supporting multiple radio technologies on a 
single subnet are involved, however, interoperability suffers if 
there is no L2-independent way of reporting on-link movement. Table 
1 contains a list of L2 handover requirements for L2 triggers. 
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L2 Trigger 

Intra-L2 
Handover Start 



Inter-L.2 
Handover Start 



Inter-L2 Old 
Link Down 



Event 

Before handover 
between two APs 
supporting the 
same radio link 
technology. 



Before handover 
between two APs 

supporting 
different radio 
link 
technologies . 



When the old L2 
link is 
disappearing and 
before disabling 
the old L2 link. 



Recipient 
Current AR 

Current AR 
MN 

(optional, only 
supplied if MN 
does not obtain 
otherwise) 



Current AR 
MN 



Parameters 

MN's new 
downlink L2 
address 

New AP's uplink 
L2 address 

MN ! s new 
downlink L2 
address (radio 
link technology 
specific) 

MN's old 
downlink L2 
address (radio 
link technology 
specific) 

New AP 1 s uplink 
L2 address 

( radio 
technology 
specific) 

MN's new 
downlink L2 
address (radio 
link technology 
specific ) 

MN's old 
downlink L2 
address (radio 
link technology 
specific) 

New AP ' s uplink 
L2 address 

( radio 
technology 
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specific) 

Table 1 - L2 Handover Requirements 
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5.0 L3 Handover Requirements for L2 Triggers 

The requirements discussed in this section have proven highly useful 
as a device in structuring low latency handover protocol designs for 
Mobile IPv4 and Mobile IPv6 [3] [4] [5] . An L2 that supports these 
requirements is a good candidate for a performance Mobile IP 
implementation. Table 2 contains the requirements for the L2 
triggers. The description for a trigger contains the trigger name, 
the L2 handover event causing the trigger to fire, what entities 
receive the trigger, and parameters, if any. The recipient is 
qualified by the IP mobility protocol in which the recipient plays a 
role. If the recipient does not have AP functionality (i.e. the 
recipient does not have an interface directly on the wireless link) , 
the trigger information must be conveyed from the AP where it occurs 
to the recipient by an L2 or L3 protocol. 
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L2 

Trigger 



Event 



Link Up When the L2 link comes 
up. 



Link 
Down 



Source 
Trigger 



Target 
Trigger 



L2 

Handover 
Start 



When the L2 link goes 
down. 



Sufficiently before L2 
handover start for 
pre-handover L3 
message exchange 
across the wired 
and/or wireless link 

Sufficiently before L2 
handover finish for 
pre-handover L3 
message exchange 
across the wired 
and/or wireless link. 

When L2 handover 
begins 



Recipient 

AP/AR 

MN 
AP/AR 

MN 



MIPV4; 



MI Pv 6 : 
MTPv4 : 



GAR o 
rlAR 

o FA or 

m 



Parameters 

MN L2 address to AP/AP 

AP/AR address to MN 

MN L2 address to AP/AR 

AP/AR address to MN 

Boolean cause 
(inadvertent /deliberate) 

nAR or nFA IP address 
or L2 address that can 
be mapped to an IP 
address 

MN L2 address 

oAR or oFA IP address 
or L2 address that can 
be mapped to an IP 
address 

MN L2 address 

MN L2 address to oAR/nAR 



MN L2 address to o FA/ nFA 



MIPv6 : oAR/nAR address or 
MIPv4 oFA/nFA address to 
MN 



Table 2 - L3 Handover Requirements 



6.0 Context Transfer Requirements for L2 Triggers 

Context transfer (CT) is a relatively new issue for supporting 
seamless mobility between two nodes that provide access to a mobile 
node. Although lacking a "de facto" CT protocol specification at 
this time, plausible approaches toward CT framework are well 
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described in [8] [9]- Conceptually, the CT framework suggests two 
distinctive modes of operation, namely, reactive and proactive. In 
this section, specific modifications to L2 triggers that suffice 
both the reactive and the proactive context transfers are discussed. 

6.1. Types of Context Transfer 



8/16/01 1:14 PM 



Reactive CT takes place subsequent to a MN establishing a new link 
with the new AR. Thus, the context information required should be 
transferred to the new access router after the MN completes the new 
link with the new access router. Although this timing requirement is 
loosely defined, it is desirable to initiate reactive CT sometime 
before (or about the same time as) the L2 handoff initiation. It is 
also noteworthy that the old access router is not always restricted 
to being the context source, i.e. where the context is transferred 
*f rom* . 

Proactive CT requires that the context is present at the new AR 
prior to the arrival of MN's packets at the new AR. The timing 
requirement for proactive CT is stricter because it may be possible 
that some of the context is still in transit when packets begin to 
arrive for the MN at the new access router. 

6.2. Requirements for L2 Triggers for Context Transfer 

Similarly as FMIP L2 triggers (as defined in Section 4.0), L2 
triggers for context transfer operating on either reactive or 
proactive mode are defined in Table 3. 
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L2 Trigger 



Event 



Recipient 



Parameters 



Proactive CT L2 Sufficiently before 
Target Trigger L2 handover 



initiation that CT 
can be completed 
before route/tunnel 
for packets to MN 
on new AR is set 
up. 



nAR 



oAR or Context 
Transfer Source 
(CTS) L2/L3 



address 
identifiers . 



MN identifier 



Proactive CT L2 Sufficiently before 
Source Trigger L2 handover 

initiation that CT 



oAR 



nAR or Context 
Transfer Target 
(CTT) L2/L3 
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Proactive CT L2 
Mobile Trigger 



Reactive CT L2 
Target Trigger 



can be completed 
before route/tunnel 
for packets to MN 
on new AR is set 
up. 

Sufficiently before MN 

L2 handover 

initiation that CT 

can be completed 

before route/tunnel 

for packets to MN 

on new AR is set 

up. 

Upon completion of nAR 
the L2 handover. 



address 
identifiers . 

MN identifier 



nAR or Context 
Transfer Target 
(CTT) L2/L3 
address 
identifiers . 



oAR or Context 
Transfer Source 
(CTS) L2/L3 
address 
identifiers 



Reactive CT L2 
Source Trigger 



Upon initiation of 
L2 handover. 



oAR nAR or Context 

Transfer Source 
(CTS) L2/L3 
address 
identifiers . 



Reactive CT L2 
Mobile Trigger 



Upon the initiation 
of L2 handover. 



MN nAR or Context 

Transfer Target 
(CTT) L2/L3 
address 
identifiers 



Table 3 - Context Transfer Requirements 
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7.0 Benefits of L2 Triggers for Other Systems 

While the primary purpose of L2 triggers described in this draft is 
to aid L2 mobility optimization, L2 triggers can also benefit 
networks without Mobile IP or other IP mobility protocol support. 
For example, IP addresses may change due to stateless or stateful 
address configuration whenever hosts are unplugged from the network 
or replugged into a different subnet. 

Use of L2 triggers in such situations enables efficient state 
managment in the AR. The AR can clean up the associated state as 
soon as it detects that a host has been disconnected through the L2 
Link Down trigger, for example. State clean up includes removal of 
ARP or Neighbor Cache entries, and can save bandwidth by inhibiting 
incoming data on the link where the host was once connected. 

Additionally, faster and more efficient router discovery is possible 
if the AR receives a L2 Link Up trigger for a host. When the AR 
receives the trigger, it can send an unsolicited unicast router 
advertisement to the host. The host can begin the process of 
establishing IP connectivity more quickly. 

8 . 0 Security Considerations 

The L2 triggers convey information about the link state of the MN 
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and this information can trigger IP layer changes in routing 
reachability. As such, the information in an L2 trigger, if misused 
by an adversary or fraudulently propagated, could result in denial 
of IP service to the MN or hijacking of the MN ' s packets to a 
hostile third party. 

If the L2 trigger is implemented as an API on an AR or AP, then the 
operating system and API implementation are required to assure that 
only qualified users can call into the API. Normally this involves 
denying access through the API unless the process running the API 
client has the proper security credentials on the host. If the L2 
trigger is implemented as an L2 or L3 protocol, the protocol is 
required to protect the trigger messages with the proper 
authentication. In particular, if the protocol is an IP-based 
protocol, it must include authenticators so the parties that use the 
protocol can authenticate each other. If the protocol is intended to 
be used on public data networks, the option of encrypting the 
traffic must be available, to grant some privacy over the MN 
movement information propagated by the protocol messages . 
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